The operation of the application is fairly obvious. Most of the defaults programmed into the application let you run the complete low-level subsystem test suite and save these results to a file with just a few keystrokes. For the sake of completeness, we'll step through its operation.
First you launch the benchmark application. The important menu here is the Low-Level Tests Menu. By default, all the tests are selected. You can use this menu to run a particular suite of tests (say, only the Disk I/O tests), a mix of tests, or a single test. When you're ready, typing Command-R runs the selected tests. To abort a test suite run, type Command-period. You'll have to wait until a test completes and returns control to the shell application before it can sense the abort command and halts running the rest of the suite.
On color Macs, before the tests run, you'll get an alert that asks you to change the screen mode to black-and-white. You should allow this mode change in order to make an accurate comparison of the results to a Classic II (our standard reference machine). However, you can disallow this mode change if you're checking out the performance of video hardware at different screen depths. Once the tests have run, you can save the results to a file. Just type Command-S and type the appropriate name into the Standard File dialog box that appears.
Under the Run menu, the debug mode uses dialog boxes to post the results as each test runs. I used this display while debugging the TextEdit portion of the code handling data logging. I left it in on the off-chance a future Mac might get annoyed at my use of TextEdit. And yes, you can turn off the Log results to window option in this menu and watch the benchmarks run without getting any information at all -- a glitch in my design. I didn't have time to write an alert that warns you of this, and now that I've frozen the code, I don't plan on fixing it until version 3.0... about PowerPC Mac or Cyclone (Mac III) time.
The benchmark application uses 68000 object code, and so should operate on a large number of Macs. It does require System 7 to run, because it makes use of the Extended Time Manager. The Extended Time Manager provides better accuracy than the Ticks() function. The Ticks() function is also prone to drift errors on certain PowerBooks as they fall asleep and awaken.
Please report any findings to:
Internet: tomt@bytepb.byte.com
AppleLink: T.THOMPSON
Remember than the goal of these low-level tests are to measure subsystem performance, and not overall system performance. Although you can get an idea of a Mac's overall behavior from these results, you should only compare subsystems to subsystems with these tests. Overall system performance requires running BYTE's application benchmark suite.
The version 2.0 low-level benchmarks were written in assembly language and THINK C version 5.0.4. by Tom Thompson. Much of the original version 1.0 benchmark code was reused for the new version. The version 1.0 benchmarks were written by Rick Grehan and Tom Thompson in Small-C and assembly language.
DISCLAIMER
Although every effort has been made to produce error-free code, neither the authors, BYTE, or McGraw-Hill are responsible for any damage or data loss that occurs when running this application.
